SlackをフリープランからEnterprise Gridに移行してみた

「ネクストモード株式会社」でSlackをEnterprise Gridに移行した経緯をまとめてみました

#リモートワーク

#ネクストモード

#SaaS

#Slack

kusumin

2021.05.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、ネクストモード株式会社のSaaSおじさん久住です。

はじめに

ネクストモードでは現在SlackのEnterprise Gridプランを利用しています。

結構前になりますがフリープランからEnterprise Gridに移行したので思い出しながら経緯をまとめておこうと思います。

Slack Enterprise Gridとは

Slackにはフリープランと有償プランがあり、有償プランにも複数のプランがあります。

Enterprise Gridプランでは複数ワークスペースを束ねて管理することで全社的にガバナンスを効かせることができます。セキュリティポリシーも柔軟に設定できるため、組織構造が複雑であればあるほど強力となってきます。

オーガナイゼーションとは

Enterprise Gridのみで存在するオーガナイゼーションについて簡単に説明します。

オーガナイゼーションはEnterprise Gridに含まれる全ワークスペースを一元的に管理できる仕組みで、オーガナイゼーション内のワークスペースに包括的なポリシーを規定したり、連携アプリケーションを一元的に管理することができます。

Enterprise Gridへの移行手順

Enterprise Gridへの移行は大きく分けて下記手順で進めました。
※2020年8月に実施した時点の情報となります。

事前準備

Enterprise Gridの初期セットアップ
SSO・ユーザプロビジョニング設定
テスト用ワークスペースへのログイン確認

既存環境の移行

既存ワークスペースをフリープランから移行

Enterprise Gridの初期セットアップ

Enterprise Gridが作成されると、事前に決めたオーガナイゼーション(OrG）のオーナにメールがくるので新規登録を開始します。

OrGオーナーのアカウント作成のために名前とパスワードを入力します。

OrG名とドメインを設定します。

利用規約とプライバシーポリシーに同意します。

以上でEnterprise Grid環境の初期セットアップは完了です。

初期設定が完了するとOrG管理画面に入ることができます。この状態ではGrid環境にはワークスペースは一つも所属しておらず、ユーザはOrgオーナー以外はいません。

SSO・ユーザプロビジョニング設定

ネクストモードではゲスト以外シングルサインオン(SSO)必須に設定しているので、OktaとのSAML連携の設定をします。合わせて、SCIMでのユーザプロビジョニングも設定しました。

シングルサインオン(SSO)とは一度の認証で複数のサービスに認証ができる仕組みのことです。認証規格は複数ありますが、SAML2.0での認証に対応しています。

ユーザプロビジョニングの自動化はユーザ情報を管理しているディレクトリにユーザが追加されると、自動的にサービス側にもユーザが作成されるようにする設定です。削除についても同様で、入退社や異動時の処理を効率化することができます。

ユーザプロビジョニングの規格としてはSCIMがあり、SlackはSCIMに対応しているので、こちらを設定していきます。

SAMLの設定

Okta側でのSAMLの設定についてはOktaの公式ドキュメントに沿って実施します。
Okta管理者画面でSlackアプリをユーザに割り当てつつ、Slack側に設定する各値を取得していきます。

Okta側で取得した値を元にSlackの公式ドキュメントを参考にSlack側でSSOの設定を進めます。
OrG管理画面のSSO設定よりSSOを構成するをクリックします。

Oktaで事前に取得した値を入力し、テスト設定を実施します。

OktaとSlackの設定が問題なく、SAMLでの認証が無事通れば更新を確認するをクリックします。

以上でSSOの設定は完了です。

SCIMの設定

OktaでSCIMでのユーザプロビジョニング設定をしておくことでOktaのユーザ・グループ情報をSlackに同期することができ、ワークスペースへのアクセス管理を効率化することができます。

OktaのSlackアプリのProvisioningでIntegrationを設定します。SlackのグループはOkta側にインポートせず、Slackの表示名はSlack上で好きに変えてもらっているため下の２つのチェックボックスは外しています。

次にTo Appにて、OktaからSlackへのユーザプロビジョニングの設定をします。OktaでのSlackアプリへのユーザ割当と割当解除に連動してSlackユーザの作成・削除をするため、Create UsersとDeactivate Usersにチェックを入れています。

テスト用ワークスペースへのログイン確認

Grid環境にテスト用ワークスペース作成

ユーザがOkta経由で問題なくログインできることを確認するため、フリープランで利用していたワークスペースを移行する前にテスト用のワークスペースを作成しました。

OrG管理画面よりワークスペースの作成を選択し、ワークスペース名とワークスペースドメインを入力します。

ワークスペースの作成が完了したら、ワークスペースにユーザを追加し、ログインしてもらいました。

OktaのSlackアプリからログインしてもらうと問題なくログインでき、ワークスペースドメインでログインしようとすると、下記の通りOktaでサインインというボタンを押してログインできました。（Oktaでサインインという文言はOrG管理者画面から変更可能です）

既存ワークスペースをフリープランから移行

前準備の説明がかなり長くなってしまいましたが、いよいよ本番です。
ここから実際にフリープランで利用しているワークスペースをEnterprise Gridへ移行していきます。 Slack社と細かくご相談させていただきながら進めさせていただき、移行の日程調整をしました。

移行の承認

移行についてSlack社側での日程承認がおりた後、移行元・移行先のプライマリーオーナーの承認が必要となります。承認依頼はSlackbotで飛んできました。

移行の実施

移行開始予定日は2020年8月28日19:00からと設定し、移行元の情報量を元にかかる時間は30分程度とSlack社から伝えられていました。
移行は19:29に完了して無事ログインできるようになっていました（よかった）。

移行中の見え方

移行する直前に社内メンバには下記のSlackbotからの通知が来たため、ワークスペースの移行が始まることを把握することができました。

移行中にSlackにアクセスすると下記の画面になっていました。

Slack Connectでつながった方には下記のような画面がでていたようです。

移行時に確認したこと

移行に伴い、個人的に気になったことをSlack社に確認させていただいたのでまとめておきます。他にも公式ヘルプページにたくさん情報は載っていますのでぜひご覧ください。

プロフィール情報の移行できるか？

もともと有償版をお使いの場合は、カスタムプロフィール（誕生日とか趣味とか）を設定可能であり、カスタムプロフィール情報の移行については下記３パターンから選択できるそうです。
（ネクストモードではフリープランからの移行だったため対象外でした）

カスタムプロフィール情報を全て移行する
カスタムプロフィール情報は移行しない（新環境で改めて整備する場合）
移行先のGrid環境に適合したプロフィール項目があれば、その項目は移行する

移行後に全てのメンバーをサインアウトさせるか？

選択肢は「Yes/No」（デフォルト設定はYes）

移行に伴い、SSO経由でのサインインに切り替わるため、サインアウトしておき、改めてエンドユーザにてサインインしていただくような手順にしておくと、「サインインしている人の場合」「サインアウトした人の場合」などのように条件に応じた案内を作る必要もないです。

移行完了後に各ユーザにEメールで通知を出すか？

選択肢は「Yes/No」（デフォルト設定はYes）

管理者にて個別に移行予定や計画を連絡するので、わざわざエンドユーザにEメール送らなくていいよ、という場合にはNoを選択するケースが多いとのことでした。念のためにお知らせしておこう、という場合はYesにしているそうです。

移行完了後にSlackbot経由で通知を送るかどうか？

選択肢は「Yes/No」（デフォルト設定はYes）

Slackbotに通知させるかどうか、の設定です。エンドユーザに何かアクションを求めるわけではなく、「新しい環境に移行したぜ！」という感じのメッセージになるため、Noに設定されるケースも多いという感触だそうです。

移行元のワークスペース名、ドメインは移行時に引き継がれるのか？

どちらも引き継がれる

移行するWorkspaceの種類（招待制、公開、非公開）はどれ？

公開設定となる

移行完了後に、OrGオーナーまたは管理者にて、他の設定（非公開・招待制・リクエスト制）に変更が必要な場合には、エンドユーザアクセスの前に設定変更していただく必要があります。

Slack Connectは問題なく移行できるのか？

移行元：Workspace-A
移行先：Grid
接続先：Workspace-B

WS-AはWS-BとSlack Connectで接続されており、WS-AがGridに移行される想定の場合
- 移行後もSlack Connectは接続継続されます
WS-AはWS-BとSlack Connectで接続されており、WS-AがGridに移行される、そしてWS-Bは元々Grid環境下にいた場合
- WS-AとWS-BはOrGチャンネルとしてマルチワークスペースチャンネルになります

さいごに

中々経験する機会のないEnterprise Gridへの移行に関われたのでまとめておこうと思ったらすごく長くなってしまいました。

ネクストモードのコアのコミュニケーションツールなのでドキドキでしたが、Slack社の多大なるご協力もあり無事移行できました（ありがとうございました！！）。 Enterprise Grid使って半年以上経ちますが、複数ワークスペースの管理やマルチワークスペース、オーガナイゼーション全体のセキュリティポリシーなど機能が充実していてとても満足しています。

今後ももっと使い倒していこうと思います。